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1. REAL PARTY IN INTEREST 

The real party in interest is General Electric Company and GE Medical Systems 
Global Technology Company, LLC, the Assignee of the above-referenced application by 
virtue of the Assignment to GE Medical Systems Global Technology Company, LLC, 
recorded on April 12, 2001, recorded at reel 01 1718, frame 0568. 

2. RELATED APPEALS AND INTERFERENCES 

Appellant is unaware of any other appeals or interferences related to this Appeal. 
The undersigned is Appellant's legal representative in this Appeal. GE Medical Systems 
Global Technology Company, LLC, the Assignee of the above-referenced application, as 
evidenced by the documents mentioned above, will be directly affected by the Board's 
decision in the pending appeal. 

3. STATUS OF THE CLAIMS 

Claims 1-21 are currently pending, and claims 1-21 arc currently under final 
rejection and, thus, arc the subject of this appeal. 

4. STATUS OF AMEND MENTS 

The Appellant submitted in the May 10, 2004 Response, amendments to 
renumber claims 13-22 as required by the Examiner in the March 8, 2004 Final Office 
Action. As indicated on page 2 of the July 8, 2004 Advisory Action, Appellant's 
amendment will be entered at appeal. 

5. SUMMARY OF THE INVENTION A IMP OF THE DISCLOSED 
EMBODIMENTS 

The present invention provides a method and system for electronically reporting 
real-time status of work in progress. An alert system is disclosed that contains both 
proactive and reactive alerts. The alert scheme is based upon an electronic warning of 
mismatched future promised delivery dates and customer requested shipping dates. The 
alerts assist with avoiding or greatly reducing any problems with meeting customer 
expectations. See Application, pe. 3. II 5 . 

In accordance with one aspect of the invention, a method for reporting status of 
work in progress is disclosed wherein a database 14 is periodically queried for 
information about product orders. The information obtained for each order includes: an 
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order number, a promise date, a request date, a shipment date, and a product category for 
a plurality of products/services offered 98, 102. The method further provides comparing 
the promise dates and the request dates 1 14. Once compared, it is decided whether an 
alert should be set 1 16, 122, including setting a proactive promise alert if a promise date 
is later than a request date for a given order 116. The proactive promise alerts with the 
order number, product category, and type of alert arc then displayed for case of action 
126, See Application, pp. 5. 11 6 . 

In accordance with another aspect of the invention, a computer- readable medium 
is disclosed, having stored thereon one or more computer programs. The computer 
program(s), when executed by one or more computers, causes the one or more computers 
to display electronic shipment alerts 126. The program begins by instructing the one or 
more computers to populate a database with data to include an order number, a promise 
date, a request date, a shipment date, and a product category for a plurality of orders 20- 
28. The one or more computers are additionally instructed to periodically query the 
database 32 and compare promise dates to request dates 1 14. Once compared, the one or 
more computers are instructed to set a proactive alert if the promise date is later than a 
request date 1 14a, and set a reactive alert if the shipment date exists and the request date 
is less than a user-defined number of days prior to a current date 122. The computer then 
displays any promise and shipment alerts organized by product category and type of alert 
126. S ee Application, pg. 3, If 7 to pg. 4 . 

In accordance with yet another aspect of the invention, a computer data signal is 
disclosed, representing a sequence of instructions, that when executed by one of more 
processors, causes die one or more processors to display proactive and reactive alerts by 
product/service category and type of aJert 1 26. The instructions first cause the one or 
more processors to populate a database with an order date indicating a date an order is 
initially made, a request date indicating a date when a customer requests delivery of the 
order, a shipment date when available indicating a date when actual shipment will occur, 
and a product/service category for each order for a product/service 98, 102. The one or 
more processors are further instructed to query the database and compare promise dates 
to request dates for each order 1 14, and to check for the entry of a shipment date for each 
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order 118. The one or more processors are then instructed to set a proactive alert 116 if 
any promise date is later than a request date 1 14a, and to set a reactive alert if a shipment 
date exists for an order and the request date is less than a user-defined number of days 
prior to a current date 120. The one or more processes are lastly instructed to display all 
proactive and reactive alerts by product/service category and type of alert 126* See 
Application , pg. 4. 8. 

6. GROUNDS OF REJECTION 

Claims 1-21 stand rejected under 35 U.S.C. §1 03(a) as being unpatentable over 
Martin et al. (USP 5,809,479) in view of Schocnbcrg et al. (USP 6,322,502). 

7. REJECTION UNDER 35 U.S.C. S103fa) OVE R MARTIN ET AL. IN VIEW 
OF SCHOENBERG ET AL ,: 

As discussed in detail below, the Examiner has improperly rejected the pending 

claims. The Examiner has misapplied long-standing and binding legal precedents and 

principles in rejecting the claims under § 103(a) of Chapter 35 of the United States Code. 

The Examiner finally rejected claims 1-21 under 35 U.S.C. §1 03(a) as unpatentable over 

Martin et al. in view of Schoenberg ct al. stating that: 

. Martin et al. discloses a method of reporting status of work in 
progress, comprising the steps of periodically querying a database that 
contains order data (see column 2, lines 30-38); comparing a promise data 
and a request data (see column 4, lines 54-65). 

Martin fails to disclose setting and displaying alerts when 
processing of an order is after a predetermined time period. 

Schoenberg et aL discloses a database monitoring function that 
allows a user to be alerted when an order is late (see column 5, lines 39- 
47). 

It would have been obvious to one of ordinary skill in the art at the 
lime Ihe invention was made to modify Martin et al. with status 
monitoring as taught by Schoenberg et aL, because status monitoring 
reminds the user that an order has not been completed and action needs to 
be taken to correct the delay. 

The Examiner takes Official Notice that proactive and reactive 
alerting systems are well known in the art and a person of ordinary skill in 
the art would recognize that alerting systems can be programmed as with 
proactive or reactive as desired by the user. 
March 8. 2004 Office Action pg. 2, 1f 5 through pg. 3, H 4 . 



4 



Oct. 4. 2004 I0M5AM ZPS GROUP LLC 



No. 5626 P. 5 



Gupta et al. U.S. Serial No. 09/747,647 

Appellant traversed the use of "Official Notice" and the Examiner acknowledged 
that the current rejection is not based on Official Notice in stating that u [a]U limitations 
are supported by the combination of Martin in view of Schoenberg." March 8, 2004 
Office Action, pg. 4, Ins. 4-5 and 10-11 . Accordingly, all previous "Official Notice" 
statements are not relevant and will not be addressed herein. 

Contrary to the Examiner's assertion, Appellant respectfully disagrees that the art 
of record supports a 35 U.S.C. § 103(a) rejection of the present claims. The burden of 
establishing a prima facie case of obviousness falls on the Examiner. MPEP §2142 . 
Obviousness cannot be established by combining the teachings of the prior art to produce 
the claimed invention absent some teaching or suggestion supporting the combination. 
ACS Hospital Systems. Inc. v. Montefiore Hospital 732 F.2d 1 57 2. 1577. 221 U.S.P.O. 
929. 933 (Fed, Cir. 1984V Accordingly, to establish a prima facie case, the Examiner 
must not only show that the combination includes each and every element of the claimed 
invention, but also provide "a convincing line of reasoning as to why the artisan would 
have found the claimed invention to have been obvious in light of the teachings of the 
references. " Ex parte Clapp. 227 USPO 972, 973 fBd. Pat. Ann, & Intcxl985l That is, 
"[o]bviousncss can only be established by combining or modifying the teachings of the 
prior art to produce the claimed invention where there is some teaching, suggestion, or 
motivation to do so found either explicitly or implicitly in the references themselves or in 
the knowledge generally available to one of ordinary skill in the art," MPEP $2143.01 . 
"The fact that references can be combined or modified is not sufficient to establish prima 
facie obviousness." Id. (emphasis added). When prior art references require a selected 
combination to render obvious a subsequent invention, there must be some reason for the 
combination other than the hindsight gained from the invention itself, i.e., something in 
the prior art as a whole must suggest the desirability, and thus the obviousness, of making 
the combination. Uniroval Inc. v. Rudkin-Wilev Com., 837 F.2d 1044, 5 U .S.P.D^d 
1434 fFed. Cir. 1988). 

To establish a prima facie case of obviousness, three basic criteria must be met. 
First, there must be some suggestion or motivation, either in the references themselves or 
in the knowledge generally available to one of ordinary skill in the art, to modify the 
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reference or to combine reference teachings. Second, there must be a reasonable 
expectation of success. Finally, the prior art reference (or references when combined) 
must teach or suggest all the claim limitations. M PEP §21 43. Appellant believes that a 
prima facie case of obviousness cannot be made based on the art of record because, as 
will be shown below, (I) the references are directed to very different purposes and 
therefore, there is no motivation to combine these references in a way done so by the 
Examiner, other than Appellant's own teaching; (II) the combination would not have a 
reasonable expectation of success because the combination would not result in the same, 
or even a similar system, as that presently claimed; and (III) all the elements of the 
present claims are not present in the references- The Examiner, as will be shown below, 
has failed to establish each of the three separate and distinct criteria necessary to support 
a § 103(a) rejection. 
CLAIM 1: 

Claim 1 calls for, in part, setting a proactive promise alert if a promise date is later 

than a request date for a given order and displaying the proactive promise alerts with an 

order number. That is, the proactive alert is displayed if a delivery delay will result if 

operation is allowed to continue without modification. Simply, when the proactive alert 

occurs, there is yet to be a delay. That is why the alert is "proactive". If an alert is 

displayed to correct an existing delay, the delay has already occurred and therefore, the 

alert is 'Yeaclive" thereto. The Examiner maintains that: 

Schoenberg teaches proactive monitoring or "reminders," as well 
as, tracking orders reactively (see column 5, lines 39-48). The motivation 
to combine comes directly from Shoenberg wherein both reactive and 
proactive alerts are taught Proactive alerts provide the user with a 
reminder that action needs to be taken in order to correct the delay ." 
May 3, 2004 Office Action : pg, 4, TJ 2 f emphasis added) . 

(I) Lack of motivation to combine references: 

Schoenberg et al. discloses a medical information system that receives patient 
data and infonnation from various sources and displays such information in a variety of 
formats for use by members of a medical team. Se e Schocn bcrfi ct al. Abstract. 
Schoenberg et al. discloses generating operational reminders for each action item that is 
transmitted between different members of a patient's medical treatment team. See 



6 



Oct. 4. 2004 10:15AM ZPS GROUP LLC No. 5626 P. 7 



Gupta et aL U.S. Serial No. 09/747,647 



Schoenberg et al. col. 5, Ins. 40-42 . Schoenberg ct aL further discloses that the system 
permits the entry of confirmatory information by respective members of a patient's 
medical treatment team and further, that if a treatment, i.e. medication, is not delivered as 
prescribed by the patient's doctor, an alarm is indicated to notify the medical team that an 
order, i.e. medicating of a patient, has not yet been carried out. See Schoenberg et aL col. 
S, Ins. 43-48 . 

The system of Schoenberg et al. provides for intercommunication between a 
plurality of individual health care personnel who may be associated with a specific 
patient. See Schoenberg et al. col. 6. Ins. 13-37. As a patient's primary physician 
determines a medication regiment for the patient, the patient's proscribed medication 
regiment is input into the system and communicated to the pharmacist who distributes the 
medications, and the resident assistants or nurses who administer the proscribed 
medications to the patient Id. 

Unrelated to Schoenberg et aL, Martin et al. discloses a system of tracking and 
reporting on-time delivery performance of goods. See Mart in et aL. Title . Martin et al. 
acquires a delivery window for individual customers. See Martin et aL, Abstrac t. The 
delivery window determines when the customer considers goods to be delivered on time. 
Id. For each subsequent order, the customer provides a customer-requested delivery date. 
Id. A customer-preferred ship date is then determined by comparing the customer- 
requested delivery date and the delivery window characteristics. Id. The system then 
shows to an order scheduler ~ a person -- the customer-preferred ship date and obtains a 
targeted ship date for the order from the order scheduler. Id. The order scheduler then 
dictates what the actual ship date will be and in so doing, knows whether a specific order 
will be delivered after a customer-requested ship date. Id, The system maintains delivery 
statistics for each customer and determines on-time delivery statistics for each customer. 
Id. That is, if an order is going to be shipped to a customer after a customer-requested 
ship date, the human order scheduler is abundantly aware of a late shipment date as it is 
that very order scheduler that dictates which orders will be delivered late. Since the 
system of Martin et al. is directed to tracking and reporting on-time delivery statistics, 
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Martin et aL acknowledges that some deliveries will be delivered after a customer- 
requested ship date and will therefore be delivered late. 

Since Martin ct al. is interested in after completion report generating, there would 
be no motivation to combine the system of Martin ct al. with any alerting function that 
may be disclosed in Schoenberg et al. That is, because the scheduler referred to in Martin 
et al. already knows that an order will be delivered after a customer-requested delivery 
date, it would be fruitless to alert the very scheduler that the date that they just knowingly 
entered is after the customer-requested delivery date. Such would be contrary to the 
teaching of the reference. As supported above, the art of record docs not teach, disclose, 
or even remotely suggest a motivation for reporting status of work in progress, including 
setting a proactive promise alert if a promise date is later than a request date for a given 
order and displaying the proactive promise alerts with the order numbers as called for in 
claim 1. 

In order to support a rejection under 35 U.S.C. § 103(a), the references must 
include a motivation to combine the references. MPEP §2142 . However, in this case, 
not only is there no motivation to combine the references within the references 
themselves, commonsensc dictates that there is no motivation to combine them at all 
since they are directed to very different purposes. Because, as will be described in 
further detail, the only logical combination of these references merely results in a preset 
mechanical reminder for the human scheduler to review each order before it becomes due 
— which he already does in Martin et al., there is no reason, and thus no motivation, to 
combine these references. 

The general nature of the system of Martin et al. is not directed to any alert 
function, cither reactive or proactive — as such is not even disclosed in Martin et al. 
Martin etal. teaches a system whereby a human sch e duler , based on manufacturing 
capacity or other parameters, changes a delivery date to a date beyond the customer 
request date. See M art in ct al. c ol. 3» In. 59 to colA In. 1 . This is accomplished by a 
manual review of all the orders. Martin et aL col. 3, Ins. 5 9?61. As the delivery date of 
Martin ct al. is controlled by the human scheduler's input upon the manual review of all 
the orders, there is no motivation in cither reference or combination thereof to include 
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any alert based upon shipment date and request date comparisons. It is clear that Martin 
et ai. requires a human scheduler to review orders and dictate the date of delivery thereby 
making the customer subject to deviations from a requested delivery date. Id As such, 
within the context of Martin ct al, there is no motivation to provide any alert - reactive 
or proactive. Martin et al. teaches that the scheduler reviews all the orders and 
manipulates the delivery date therefore he already knows that a specific delivery will 
be late. Martin et al, col. 3. Ins. 61-66. As such, there is no motivation to provide an 
alert for that which is already known. Therefore, as shown above, the art of record does 
not include the motivation to combine the references in the maimer done by the 
Examiner. 

(II) Lack of reasonable expectation of success: 

The second independent element required to support a 35 U.S.C. §103(a) rejection 
is that there must be a reasonable expectation of success in combining the references. 
MPEP §2142 . There is no such reasonable expectation of success in the present case. 
Claim 1 calls for, in part, setting a proactive promise alert if a promise date is later than a 
request date for a given order. First, the system of Schoenberg et al. docs not include any 
request dates. Appellant is unaware of any medicinal distribution system wherein the 
patient — i.e. the customer of Schoenberg et al. requests a time of medication. Because 
the doctor dictates when the patient will be medicated, "request dates" are wholly absent 
in this reference. See Schoenberg et al col. 5. Ins. 38-48 . Second, if an alert is generated 
for every order of Martin et al. 7 as suggested by the preset mechanical reminders of 
Schoenberg ct al., then after the scheduler of Martin et al. reviews the orders, and he 
moves an order so that the promise dale is later than a request date, the system would 
then immediately generate an alert, according to Schoenberg et al., to alert the very 
scheduler who moved the data just seconds before. Since the scheduler already knows 
that the delivery date is after the customer-requested delivery date ~ the scheduler does 
not need an alert and, in fact, it would hinder his performance by requiring that he now 
must clear an alert of the condition he just created. S ee Martin et al. col. 3. In. 61 to col. 
4. In. 1 . What purpose would that serve? 
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Martin et al. teaches altering the delivery date beyond the customer-requested 
delivery date in response to production shortcomings. See Martin et al. col. 4. Ins. 41-43. 
That is, the customer is still subject to the supplier dictating when delivery will take place 
rather than alerting the supplier that a late delivery will occur and allowing alteration of 
the production schedule to prevent such occurrences. Simply, Martin ct al. tracks 
delivery problems rather than resolving the delivery problems prior to affecting the 
customer. Id. The present invention, by providing proactive alerts when a promise date 
is later than a request date, allows a supplier to adapt to production shortcomings to 
prevent late deliveries rather than making the customer subject to such limitations, or at 
the very least, allows early warning to notify the customer rather than simply statistically 
calculating late deliveries, as is the case in Martin el al Id. A reasonable combination of 
these references does not result in the claimed invention, nor would it achieve the 
advantages — or successes of the present invention. The only reasonable combination of 
the references results in the human order scheduler of Martin et al. clearing a reminder 
for every order that he himself elects to deliver late. As the human order scheduler of 
Martin et al. acknowledges that late orders are acceptable — by setting a ship date after a 
request date - providing any reminder that an order will be late merely reminds the 
human order scheduler of that which they already know. Accordingly, there is a 
complete lack of a reasonable expectation of success for such a combination. 

(Ill) Lack of references teaching, showing, or disclosing all the elements of 
the present claims: 

Schoenberg et al. states that "[cjompliance with orders is tracked as well, and the 
display screen can indicate an alarm or other warning indicator which notifies the 
medical team that an order has not vet been carried out ." Schoenberg et al. col. 5, Ins. 45- 
48 (emphasis added) . As the Examiner states, Schoenberg ct al. discloses an alert that is 
provided when an order is already late, or has not yet been carried out, but in any case, it 
is already late - it has not been delivered on time. See Id , Granted, Schoenberg et al. 
does provide reminders before the action is required, but it only docs so with a preset 
period of time. For example, if a doctor prescribes a certain patient be provided with a 
specific medication, a reminder is sent for each respective patient reminding the balance 
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of the medical team that the prescription is expected to be administered. Schoenberg et 
al. col. 5. Ins. 41-42 . 

Claim 1, however, calls for a proactive alert if "a promise date" i$ later than "a 
request date" for a given order. Appellant is unaware of any medication that is promised 
in response to a patient's requested date of delivery . That is, the medication is to be 
delivered according to a doctor's predetermined administering procedure or date. The 
patient is medicated according to the doctor's advice, not the patients* request, and an 
alert is generated if the medication has not been administered in accordance therewith. 
This alert is reactive to a late order and therefore is not proactive lo prevent such 
occurrences. Further, there is absolutely no comparison of a promised date to a request 
date — none. Schoenberg et al. discloses, no request date whatsoever, for if it did, it 
would be a "request" by it's customer — the patient — and that makes no sense in the 
context of Schoenberg et aL 

The step of setting a proactive promise alert if a promise date is later lhan a 
request dates for a given order, as called for in claim 1, is therefore completely absent 
from both references. One reference, Schoenberg et al., has no request date for a given 
order, and the other reference, Martin et al., sets no alerts whatsoever. Further then, 
neither reference teaches, suggests, or even hints at "displaying the proactive promise 
alerts with the order numbers." These elements are wholly absent in both references. 

Additionally, as stated in the present Specification: n [t]he word 'proactive' is 
meant to show that an aJert may be set while there is still time to rectify a possible 
problem in the process, in this case, shipping." Specification, pg. 16, ^[ 38, Ins. 3-5 . "The 
proactive alert allows the process owners to make adjustments or take special action in 
order to avoid a late shipment.' 1 Specification, pg. 16, If 38. Ins. 5-6 . The Schoenberg et 
aL alert is not proactive in that the alert is not generated to ^cjpatc a problem, but is 
generated to notify that a problem already exists, i.e., the order is already late. Clearly, 
such an alert is reactive to an error condition and is not proactive to prevent such errors. 
Simply, Schoenberg et al. discloses providing alerts after missing the required action. 
This may make sense for Scheonberg et al. since the time for corrective action is minimal 
— i.e. medication can then be quickly given to the patient. However, such reactive alerts 
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are not always practicable, especially in a manufacturing facility. That was a major 
consideration in why the present invention was developed — to overcome these 
shortcomings by allowing correction of a potential defect in the process that would result 
in a delay if not corrected - setting and displaying of proactive alerts based on a specific 
set of criteria, as claimed. 

Martin et al., being directed to on-time delivery performance, teaches that late j 
deliveries are addressed with deliveries after the requested delivery date and reports late 
deliveries for later corrective action based on statistical evaluation. That is, when the 
scheduler inputs a delivery date that is after a customer-requested delivery date, the 
scheduler acknowledges, or dictates, that a delivery will be late. Martin et al. col. 4, Ins. 
33-44 . Martin et al. states that "database maintenance is typically performed by customer 
service representatives of the supplier, from within the suppliers order processing 
computer system." Martin et al. col. 2, Ins. 43-47 . Martin et al. further states that . .the 
computer system is programmed to show the order scheduler the calculated customer- 
preferred ship date and to obtain from the sche duler a targeted ship date for the customer 
order entry," Martin et al. col. 3. Ins. 63-67 (emphasis added) . That is, the system of 
Martin et al. is reactive to scheduler inputs, not proactive to rectify delivery problems as 
is specifically called for in claim 1 . 

The system of Martin et al. ",.,is programmed in a step 30 to generate on-time 
product delivery statistics for individual customers." Martin et al. col. 4. Ins. 54-57 . That 
is, the system does not report the status of work in progress but reports the status of . 
completed work. As shown in the chart in Column five (5) of Martin et ah, the system 
generates an on-time shipping report. Martin et al. col. 5, Ins. 5- 26. That is, the work is 
already completed and is either late or on time. Such a system is therefore wholly 
reactive to delivery difficulties rather than proactive to overcome processing 
considerations to directly improve delivery performance - - in real time. See Martin et 
al., claim 5 . Martin et al. slates that 'The system and program described above allow a 
supplier to easily measure its performance using the same evaluation criteria used by its 
customers." Martin ct al. col . 5. In s . 47-49 (emphasis added) . In other words, the work 
needs to be completed in order to measure the performance. As such, the system of 
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! 

Martin ct al. does not teach, or even suggest, monitoring the status of work in progress as 
the customer is only interested in delivery — or work that is already completed. 

For all the reasons set forth above, Appellant believes that the art of record fails to j 
establish each requirement, as required under MPEP §2142, of substantiating a 35 U.S.C. ) 
§ 103(a) rejection of claim L As the art of record lacks the motivation to combine the 
references in the manner done by the Examiner, lacks a reasonable likelihood of success, ' 
and fails to teach or suggest each and every clement of claim 1, Appellant believes claim j 
1 , and those claims that depend therefrom, are patentably distinct over the art of record. 
Appellant believes claims 2-6 and 8 are in condition for allowance at least pursuant to the 
chain of dependency. However, since Appellant believes claim 7 includes subject matter 
that is additionally distinguishable from the art of record, Appellant will specifically 
address that which is patentably distinct above and beyond the allowability of the claim ■ 
pursuant to die chain of dependency, 

CLAIM 7: 

Claim 7 further defines claim 1 wherein the proactive promise alert allows for J 
correction of a potential late shipment and a reactive shipment alert provides data to 
prevent future late shipments. As argued above with respect to claim 1, the customers of 
a supplier operating under the system of Martin et aL are subject to orders being delivered 
late as dictated by a human order scheduler. See Martin et al. col. A Ins. 34-45 . There is 
no disclosure in either Martin et aL or Schoenberg et al. tor a proactive alert to allow for 
the correction of a potential late shipment as called for in claim 7. That is, rather than \ 
merely recording and maintaining data of late deliveries, as taught by Martin et al., the = 
system of the present invention prevents, or significantly reduces, such occurrences by 
providing proactive alerts to allow for the correction of potential late shipments prior to a 
missed delivery date. See Specification pg. 16, 1138. Ins. 5-8 . The present invention is 
clearly an improvement over the system of Martin ct al. wherein the customers delivery 
date is subject to a delivery date dictated by a supplier scheduler. See Martin et ah col. 4, 
Ins. 34-44 . As such, claim 7 contains subject matter that is patentable, independent from 
that of claim 1. 
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CLAIM 9: 

Claim 9 calls for, in part, a computer-readable medium having stored thereon one 
or more computer programs that, when executed by the one or more computers, causes 
the one or more computers to: populate a database, set a proactive alert if a promise dale 
is later than a request date, set a reactive alert if a shipment date exists and the request 
date is less than a user-defined number of days prior to a current date, and display any 
promise and shipment alert by product category and type of alert. 

Again, the burden of establishing a prima facie case of obviousness falls on the 
Examiner, MPEP $2142 , To establish a prima facie case, the Examiner must show (I) 
there is a suggestion, or motivation, either in the references themselves or in the 
knowledge generally available to one of ordinary skill in the art to modify the reference 
or combine the reference teachings, (II) a reasonable expectation of success, and (III) the 
references must teach or suggest all the claim limitations. MPEP S2142 . Again, 
Appellant docs not believe that the Examiner has met each or any of the criteria required 
lo establish a prima facie case of obviousness as required under MPEP §2142. 

(I) Lack of motivation to combine references: 

Again, in order to support a 35 U.S.C. § 103(a) rejection, the references must 
contain the requisite motivation to combine the references. MPEP $2142 . Not 
withstanding the reference's failure to teach or suggest each and every element of claim 9 
as will be discussed further below, the art of record fails lo provide a motivation to 
combine the references. Additionally, as stated in MPEP §2143.01, "the level of skill in 
the art cannot be relied upon to provide the suggestion to combine references." MPEP 
62143.01, Al-Site Corp. v. VSI Int'l Inc.. 174 F.3d 1308, 50 USPQ2d 1161 (Fed. Cir. 
1999) . As previously argued with respect to claim 1, as Martin et aL allows a scheduler 
to set a delivery date later than a request date, there is no motivation for the system of 
Martin et al. to provide any alerts. The scheduler, by setting a delivery date after a 
request date, already knows that the delivery will not meel the customer's request date. 
Additionally, as Martin et al. is directed to teaching and supporting on-time delivery 
performance, there is no motivation for any alerting function, let alone (1) a proactive 
alert if a promise date is later than a request date and (2) a reactive alert if the shipment 
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date exists and the request date is less than a user-defined number of days prior to the 
current date as specifically called for in claim 9. Furthermore, the lack of the relatedness 
in the on-time delivery, tracking and reporting system of Martin et aL and the medical 
information system of Schoenberg et al. further supports the lack of motivation of one 
skilled in the art to combine the references in the manner suggested by the Examiner. 

As such, not only does the art of record fail to teach or suggest each and every 
clement of claim 9 as will be discussed further below, but the art of record also fails to 
suggest a motivation to combine the references as the Examiner has done. 

(II) Lack of reasonable expectation of success: 

As previously argued with respect to claim 1, a reasonable combination of 
Schoenberg et al. and Martin ct al. would result in nothing more than the scheduler, a 
person, receiving a reminder to look at each and every entry and reschedule the delivery 
date if the promised delivery date cannot be met. This would add nothing of substance to 
Martin ct al. Such a redundant, manual rescheduling system is not what is presently 
claimed. The present invention, as defined in claim 9, calls for an automated system that 
sets and displays both (1) proactive alerts if a promise date is later than a request date and 
(2) reactive alerts if a shipment date exists and the request date is less than a user-defined 
number of days prior to a current date. As previously argued with respect to claim 1, any 
combination of Schoenberg et al. and Martin et al. does not yield the advantages or 
success of the present invention. Simply, the combination results in the human order 
scheduler of Martin ct al. being "reminded" that the order scheduler has just dictated a 
delivery date that is later than a request date. This '"reminder" serves no purpose as the 
order scheduler is the one who moved the date of delivery to a date after a request date. 

(III) Lack of references teaching, showing, or disclosing all the elements of 
the present claims: 

As argued with respect to claim 1, the art of record fails to teach or suggest 

proactive alerting. Schoenberg et al states that: 

The system provides for the entry and monitoring of action items, 
such as, for example, orders for drugs or other treatments. Operational 
reminders are then generated and transmitted to the medical team. The 
system further permits entry of confirmatory information by the 
appropriate member of the team to verify that an order has been carried 
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out. Compliance with orders is tracked as well, and the display screen can 
indicate an alarm or other warning indicator which notifies the medical 
team that an order has not yet been carried out. 
Schoenberg ct al. T Col. 5. Ins. 38-48 . 

The Examiner states that "Schoenberg et al. teaches proactive monitoring or 

'reminders, 1 as well as tracking orders reactively (see col 5, Ins. 39-48)" and that "the 

motivation to combine comes directly from Schoenberg, wherein both reactive and 

proactive alerts are taught." March 8. 2004 Office Action pg. 4, Ins. 18-21 . The 

Examiner further states that "proactive alerts provide the user with a reminder that action 

needs to be taken in order to correct the delay," Id.. Ins. 21-22 . Appellant respectfully 

disagrees. 

As argued above with respect to claim 1 and defined in the present Specification: 
"[t]he word 'proactive' is meant to show that an alert may be set while there is still time to 
. rectify a possible problem in the process, in this case, shipping." Specification, pg. 16, If 
38, Ins. 3-5 . "The proactive alert allows the process owners to make adjustments or take 
special action in order to avoid a late shipment." Specification, pg. 16, 38, Ins. 5- 6. 
Simply, a reminder is not an alert, and claim 9 further calls for how/when the alert is set. 
As previously argued with respect to claim 1, if the prescribing doctor of Schoenberg et 
al sets the "promise date", there is no "request date" at all in Schoenberg et al.. 

The Examiner's statement that "proactive alerts provide the user with a reminder 
that action needs to be taken in o rder to correct the delay " is inconsistent with that taugjit 
by Schoenberg et al.. See March 8. 2004 Office Action, pa. 4, Ins. 21-22 . Unlike a 
proactive alert, a reminder, as disclosed in Schoenberg et al., is generated for all action 
items and does not indicate a future failure if unaddressed. See Schoenberg et al. col. 5, 
Ins. 38-42 . That is, the reminder is nothing more than a schedule of intended actions and 
does not indicate a problem will occur due to the scheduling of the action items. 
Schoenberg et al, discloses indicating an alarm only in the event that an order has not 
been carried out prior to a prescribed medication period. Scho enbe rg ct al . col.JLlns^ 
45-48 . As such, the alarm of Schoenberg et al. is reactive to incomplete action items. 
Schoenberg ct al. discloses reactive alerts in response to action items that have failed to 
be carried out on an individual basis. Id. There is no disclosure in Schoenberg ct al. or 
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Martin et al. for setting a proactive alert if a promise date is later than a request date and 
displaying any alerts by product category and type of alert, as called for in claim 9. 

Claim 9 is further defined as a computer readable medium having stored thereon 
one or more computer programs that, when executed by one or more computers, causes 
the one or more computers to periodically query a database, set a proactive alert if the 
promise date is later than a request date, set a reactive alert if the shipment date exists and 
the request date is less than a user-defined number of days prior to a current date, and 
display any promise and shipment alerts by product category and type of alert That is, it 
is the system of the present invention that queries, sets, and displays any alerts that may 
be generated responsive to data queried from the database. As previously argued with 
respect to claim 1, it is not the system of Martin et al. that performs any of the claimed 
functions but the scheduler — a person ~ interacting therewith. While Applicant does not 
necessarily disagree that the system of Martin et ah performs various calculations, the 
system disclosed does not populate a database, periodically query the database, or set and 
display any alerts. All of which are called for in claim 9. 

Claim 9 further calls for displaying any promise and shipment alerts by product 
category and type of alert . As previously argued with respect to claim 1, Martin et al. 
does not disclose any alerts. Furthermore, Schoenbcrg et al. only discloses reactive alerts 
generated in response to a missed action item. Schoenberg et al. col 5, Ins. 45-49 . As 
such, a combination of the references would render only one type of alert ~ a reactive 
alert. As such the references do not teach, suggest, or disclose displaying the type of alert 
since only one "type" of alert is generated in Schoenberg et al. There would be no reason 
to display the type of alert as called for in claim 9 as the combination of references only 
generates only one "type" of alert As such, the art of record does not teach or suggest 
each and every element of claim 9 as required under MPEP §2142. 

For all the reasons set forth above, Appellant believes that the art of record fails to 
establish each requirement, as required under MPEP §2142, of substantiating a 35 U.S.C. 
§ 103(a) rejection of claim 9. As the art of record lacks the motivation to combine the 
references in the manner done by the Examiner, lacks a reasonable likelihood of success, 
and fails to teach or suggest each and every element of claim 9, Appellant believes claim 
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9, and those claims that depend therefrom, are patentably distinct over the art of record. 
Accordingly, Appellant requests favorable action over the rejection of claims 9-14 over 
Martin et al. in view of Schoenberg et aL 

CLA I M 15: 

Claim 15 calls for, in part, a computer data signal representing a sequence of 
instructions that, when executed by one or more processors, causes the one or more 
processors to queiy a database and compare promise dates to request dates for each order 
and check for the entry of a shipment date for each order and set a proactive alert if any 
promise date is later than a request date. 

(1) Lack of motivation to combine references: 

As argued above with respect to claims 1 and 9, there is no disclosure in either 
Martin et al. or Schoenberg ct al. for a system that sets a proactive alert if any promise 
date is later than a request date. Appellant does not necessarily disagree that Schoenberg 
et al. discloses providing reminders; however, as argued above with respect to claim 1, 
Schoenberg ct al. teaches generating preset reminders for each and every action item and 
only generating a reactive alert if an action has not been completed. Schoenberg ct al 
col. 5. Ins. 44-48 . 

Claim 15 defines the proactive alert as being generated if a promise date is later 
than a request date . That is, the proactive alert is not a reminder that is generated for 
every action but is an alert that is indicative of a pending action failure if unaddressed. As 
defined in the present Specification, the proactive alert is intended tfc to show that an alert 
may be set while there is still time to rectify a possible problem in the process, in this 
case, shipping." Specification, pg. 16. t 38. Ins. 3-5 . A reminder is not an alert in that 
there has not been a determination that if any promise date is later than a request date as 
called for in claim 15. The 'Yeminder" of Schoenberg et al. is generated for each action 
item and is therefore not determined from any date comparison as called for in claim 15. 
See Schoenberg et al . col. 5. Ins. 41-42. Additionally, as previously argued with respect 
to claim 1 , there is no motivation, or support for the conclusion, that the system of Martin 
et al. include any alert. Any late delivery of Martin ct al. is dictated by a human order 
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scheduler that creates such a situation — so he would not henefit from such an alert. 
Martin et ah col. 4, Ins. 34*44 . 

Claim 15 further calls for the one or more processors to set a reactive alert if a 
shipment date exists for an order and the request date is less than a user-defined number 
of days prior to a cunrent date. As argued above with respect to claim 9, because the 
"system" of Martin ct ah is directed to on-time delivery tracking and reporting, and 
because Martin et ah discloses that a human scheduler can dictate a delivery date beyond 
a request date - as stated in Martin et ah column 4, lines 33-44 — there is no motivation 
to provide an alert that an order will be delivered beyond the request date when the 
scheduler must input such information and, therefore, is already aware that a late delivery 
will occur. 

Claim 15 further defines that the one or more processors display all proactive and 
reactive alerts by product/service category and type of alert. As previously argued with 
respect to claim 9, as Martin et ah does not disclose generating any alerts and Schoenberg 
et al. only discloses generating reactive alerts to medications that are not timely 
administered, there is no motivation in the art of record for displaying the type of alert 
Only one alert « a reactive alert — is disclosed in Schoenberg et ah and no alerts are 
disclosed or useful in Martin ct al. Claim 15 calls for setting proactive and reactive alerts 
and displaying all alerts as well as the type of alert. As Schoenberg ct al. discloses 
generating one type of alert, a reactive alert, there is no motivation to display that any 
alert generated is a reactive alert as that is the only type of alert the system of Schoenberg 
et al. is capable of generating. Such an interpretation creates a redundancy in that only a 
reactive alert is generated by the applied art. That is, since the art discloses onJy one type 
of alert, the art not only does not display the type of alert, as called for in claim 15, but 
lacks any motivation for such a display. As such, not only does the art fail to teach or 
suggest both proactive and reactive alerts, but the applied art also fails to teach or suggest 
displaying the type of alert as only one type of alert can be generated by the systems 
disclosed therein. 
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! 

(II) Lack of reasonable expectation of success: 

Claim 15 calls for, in part, a sequence of instructions thai cause one or more ' 
processors to: set a proactive alert if any promise date is later than a request date, set a 
reactive alert if a shipment date exists for an order and Ihe request date is less than a user- 
defined number of days prior to the current date, and displaying all proactive and reactive 
alerts by product/service category and type of alert. 

As previously argued with respect to the lack of reasonable expectation of success i 
with respect to claims 1 and 9, the art of record fails to achieve that which is called for in 
claim 15. The '"reminders" of Schoenberg et aL are not generated by any date 
comparison. Schoenberg et aL merely discloses generating reminders for each action j 
item. Schoenberg et al. coL 5. Ins. 41-42. As these reminders are generated after the 
entry of action items, any date associated therewith would be a delivery date. As such, 
there is no setting of a proactive alert if a promise date is later than a request date as ; 
called for in claim 15. The combination suggested by the Examiner would merely 
require the order scheduler of Martin et aL to repeatedly clear reminders that do not i 
indicate that a promise date is later than a request date but are merely mechanically 
created for each action item and do not indicate anything other than that an order has 
been placed. Such a system would clearly not achieve the benefits and success of the 
present invention. 

(JIT) Lack of references teaching, showing, or disclosing all the elements of j 
the present claims: j 

As previously argued with respect to claims 1 and 9, claim 15 calls for, in part, a 
computer data signal representing a sequence of instructions that cause one or more | 
processors to set a proactive alert if any promise date is later than a request date, set a i 
reactive alert if a shipment date exists for an order and the request date is less than a user- 
defined number of days prior to the current date, and displaying all proactive and reactive j 
alerts by product/service category and type of alert. As extensively argued and supported 
above, the art of record does not teach, disclose, or suggest setting a proactive alert if any 
promise date is later than a request date, as also called for in claim 15. 
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Appellant does not disagree that Schoenberg et al. discloses generating reactive 
alerts for action items that arc not completed by a delivery date. Schoenberg et al. col. 5, 
Ins, 45-48 . That is not what is called for in claim 1 5. Claim 1 5 calls for setting a reactive 
alert if a shipment date exists for an order and the request date is less than a user-defined 
number of days prior to a cun-ent date. The alert of Schoenbcrg ct al. is generated only 
after the action item has not been completed by the delivery date. Additionally, the 
system of Martin et al. discloses that a human order scheduler dictate a delivery date later 
than a request date. Martin et al col 3, Ins. 61-66 . As such, setting a reactive alert by a 
computer data signal if a shipment dale exists for an order and the request date is less 
than a user-defined number of days prior to the current date, as called for in claim 15, is 
also not taught, shown, or even suggested in the art of record. 

Claim 15 further calls for the display of all proactive and reactive alerts by 
product/service category and type of alert. As previously argued with respect to claim 9, 
there is no support in the art of record for the display of the 'type" of alerts. Schoenberg 
ct al. only discloses one type of alert and Martin et al. does not disclose any alerts. As 
such, the art of record fails to teach, suggest, or disclose displaying the type of alert since 
only one type of alert is generated by the combination of these references ~ a reactive 
alert. 

Minimally, three distinct elements of claim 1 5 are not taught, shown, or disclosed 
in the art of record. In addition thereto, as argued above, the references lack the 
motivation to combine the references in the manner done by the Examiner and lack a 
reasonable likelihood of success by any combination thereof. For all the reasons set forth 
above, Appellant believes that the art of record fails to establish each and every 
requirement, as required under MPEP §2142, of substantiating a 35 U.S.C. §103(a) 
rejection of claim 1 5. As the applied art lacks the motivation to combine the references 
in the manner done by the Examiner, lacks a reasonable likelihood of success, and fails to 
teach or suggest each and every clement of claim 15, Appellant believes claim 15, and 
those claims that depend therefrom, arc patcntably distinct over the art of record. 
Accordingly, Appellant requests favorable action over the rejection of claim 15 over 
Martin et al. in view of Schoenbcrg et al. 



21 



Oct. 4. 2004 10:1 8AM 



ZPS GROUP LLC 



No- 5626 P. 22 



Gupta ct al. 



U.S. Serial No. 09/747,647 



8. CONCLUSION 

In view of the above remarks, Appellant respectfully submits that the Examiner 
has provided no supportable position or evidence that claims 1-21 arc obvious under 35 
U.S.C. § 103(a). Accordingly, Appellant respectfully requests that the Board find claims 
1-21 patentable over the prior art of record, direct withdrawal of all outstanding 
rejections, and direct the present application be passed to issuance. 

General Authorization fo r Extension of Time 

In accordance with 37 CF.R. §1.136, Appellant hereby provides a general 
authorization to treat this and any future reply requiring an extension of time as 
incorporating a request therefore. Prior authorization has been given authorizing 
charging Deposit Account No. 07-0845 fees associated with the above-captioned matter. 
Accordingly, Appellant requests that the $340.00 fee for filing this Appeal Brief Under 
37 C.F.R. §1.1 7(c) and the $110.00 one-month extension fee be charged against Deposit 
Account No. 07-0845. 
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APPE NDIX OF CLAIMS ON APPEAL 

1 . (Previously Presented) A method for reporting status of work in progress, 
comprising the steps of: 

periodically, querying a database that contains data indicating an order 
number, a promise date, a request date, a shipment date, and a product category for a 
plurality of products/services offered; 

comparing the promise dates and the request dates; 

setting a proactive promise alert if a promise date is later than a request 
date for a given order; and 

displaying the proactive promise alerts with the order numbers. 

2. (Original) The method of claim 1 further comprising the steps of: 
setting a reactive shipment alert if the shipment date exists and the request 

date is less than a user-defined number of days prior to a cun-ent date; and 

displaying any reactive shipment alerts with the order number together 
with the proactive promise alerts. 

3. (Original) The method of claim 2 wherein the user-defined number of 
days is equivalent to a number of days required for shipping a product to a customer. 

4. (Previously Presented) The method of claim 1 wherein the querying of the 
database is conducted automatically at regular time intervals, and wherein the step of 
displaying is further defined as displaying the proactive promise alerts with the order 
numbers by product category and type of alert. 

5. (Original) The method of claim 1 wherein the steps of the method are 
repeated automatically in real time. 

6. (Original) The method of claim 1 further comprising repeating the steps 
of the method every time a request for information is made. 
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7. (Original) The method of claim 2 wherein the proactive promise alert 
allows for correction of a potential late shipment and the reactive shipment alert provides 
data to prevent future late shipments. 

8. (Original) The method of claim 1 further comprising the steps of reacting 
to a proactive alert by performing one of: 

modifying the promise date to coincide with the request date; and 
notifying a customer that the request date cannot be fulfilled as desired. 

9. (Original) A computer-readable medium having stored thereon one or 
more computer programs that, when executed by one or more computers, causes the one 
or more computers to: 

populate a database with data to include an order number, a promise date, 
a request date, a shipment date, and a product category for a plurality of orders; 

periodically query the database and compare promise dates to request 

dates; 

set a proactive alert if the promise date is later than a request date; 
set a reactive alert if the shipment date exists and the request date is less 
than a user-defined number of days prior to a current date; and 

display any promise and shipment alerts by product category and type of 

alert. 

1 0. (Original) The computer-readable medium of claim 9 wherein the user- 
defined number of days is equivalent to a number of days required for shipping a product 
to a customer or providing a service to a customer, 

11. (Original) The computer-readable medium of claim 9 wherein the query 
of the database is conducted automatically at regular time intervals. 
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12. (Original) The computer-readable medium of claim 9 wherein the one or 
more computer programs cause the one or more computers to repeat the actions of claim 
9 every time a request for information is made. 

13. (Original) The computer-readable medium of claim 11 wherein the 
regular time interval is between 0 and 60 seconds. 

14. (Original) The computer-readable medium of claim 1 1 wherein the 
regular time interval is greater than 1 minute. 

1 5. (Original) A computer data signal representing a sequence of instructions 
that, when executed by one of more processors, cause the one or more processors to: 

populate a database with an order date indicating a date an order is 
initially made, a request date indicating a date when a customer requests delivery of the 
order, a shipment dale, when available, indicating a date when actual shipment will occur 
and a product/service category for each order for a product/service; 

query the database and compare promise dates to request dates for each 
order and check for the entry of a shipment date for each order; 

set a proactive alert if any promise date is later than a request date; 

set a reactive alert if a shipment date exists for an order and the request 
date is less than a user-defined number of days prior to a current date; and 

display all proactive and reactive alerts by product/service category and 

type of alert. 

1 6. (Original) The computer data signal of claim 15 wherein the user-defined 
number of days is equivalent to a number of days required for shipping a product/service 
to a customer. 

17. (Original) The computer data signal of claim 1 5 wherein the query of the 
database is conducted automatically at regular time intervals. 
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18. (Original) The computer data signal of claim 15 wherein the computer 
data signal causes the one or more processors to repeat the actions of claim 15 every time 
a request for information is made. 

19. (Original) The computer data signal of claim 17 wherein the regular time 
interval is between 0 and 60 seconds. 

20. (Original) The computer data signal of claim 17 wherein the regular time 
interval is greater than 1 minute. 

21. (Original) The computer data signal of claim 15 wherein the computer 
data signal causes the one or more processors to allow user modification of the promise 
date to coincide with the request date in response to the proactive alert if the 
product/service is available by the request date. 
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